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jLYiy name is Frank Kuo and I'm with SRI International. It's my 
honor and privilege to introduce Larry Roberts, who was the fourth 
director of ARPA IPTO and really the father, although not the inventor, 
of packet switching. Larry Roberts . . . 


Frank Kuo 
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The ARPANET and Computer Networks 


Lawrence G. Roberts is Founder, Chairman, and CEO of 
NetExpress, Inc., and Director of DHL Corporation. Dr. 
Roberts has been deeply involved in the development of 
the data communications industry since the early 1960s 
and is considered the architect of packet switching technol¬ 
ogy. Dr. Roberts has B.S., M.S., and Ph.D. degrees in Elec¬ 
trical Engineering from MIT. Formerly the Director of 
Information Processing Techniques at the Advanced Re¬ 
search Projects Agency (ARPA) of the Department of De¬ 
fense, Dr. Roberts was responsible for the initiation, 
planning, and development of ARPANET, the world's first 
major packet network. He was also responsible for a broad 
program of computer communication research, including 
computer security, speech compression and understand¬ 
ing, satellite communications, and computer system de¬ 
sign. 

In 1973 Dr. Roberts founded Telenet Communications 
Corporation, the world's first packet switched data com¬ 
munications carrier, serving as President and CEO. In 1982 
he left Telenet (now merged with GTE) and joined DHL as 
President of DHL Corporation, founding NetExpress and 
initiating the DHL Domestic Overnight Service. Dr. Rob¬ 
erts has received numerous awards, including the Secre¬ 
tary of Defense Meritorious Service Medal, the Harry 
Goode Memorial Award from the American Federation of 
Information Processing, the IEEE Computer Pioneer 
Award, the Interface Conference Award, and in 1982, the 
L.M. Ericsson prize for research in data communications. 
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The ARPANET and Computer Networks 

Laurrence G. Roberts 

NetExpress, Inc. 


In 1964 only large mainframe computers existed, each with its own 
i separate set of users. If you were lucky the computer was time-shared, 

^ but even then you could not go far away since the terminals were hard- 

wired to it or connected by local phone line. Moreover, if you wanted 
data from another computer you moved it by tape and you could for- 
p get wanting software from a different type of computer. Thus, most 

users were tied by their computer and terminal to a very restricted 
environment. 

Today, your terminal could well be a microcomputer networked 
with a very large, worldwide collection of other computers. You can 
obtain data and software from all these computers relatively easily 
(with room for improvement) or, where convenient, use the software 
and data on its home computer by remote access, computer to com¬ 
puter. 

This change, which has occurred over the past 20 years, is in part 
a massive and evolutionary change in computer technolog)', and in 
part a modest and revolutionary change in communications technol¬ 
ogy. The revolution in communications started with an experiment in 
computer networking, the ARPANET, and grew into a communi¬ 
cations revolution called packet switching. Today virtually all the world 
is linked by packet switched communications service so that any termi¬ 
nal can access almost any computer in the world. This packet switched 
data network has grown up independent of the telephone network, 
but over the next 20 years the basic fabric supporting all switched ser¬ 
vices (data, telephone, and video) appear likely to become converted 
to packet switching, completing the revolution. 


History of Network Concepts 

Going back to examine the history of computer networks, the first 
event for me took place in November 1964 at the Second Congress on 
the Information System Sciences in Hot Springs, Virginia. In informal 
discussions with J. C. R. Licklider, F. Corbato, and A. Perlis, I con¬ 
cluded that the most important problem in the computer field before 
us at that time was computer networking; the ability to access one com¬ 
puter from another easily and economically to permit resource sharing. 
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The ARPANET and Computer Networks 

That was a topic in which Licklider was very interested and his enthu¬ 
siasm infected me. My interest was more toward the networking and 
communications issues rather than the computer language and 
compatibility issues that were foremost in Lick's mind. For at least the 
prior year, Licklider, who was then running the ARPA IPT office (then 
called Command & Control Research), had been pursuing the concept 
of the "Intergalactic Computer Network," trying to define the prob¬ 
lems and benefits resulting from computer networking. In any case, 
that Hot Springs discussion convinced me that I should change my 
career objectives to concentrate on computer networking and the re¬ 
lated communications problems. 

One year later, in 1965, a second important meeting took place at 
MIT. Donald Davies from the National Physical Laboratory in the 
United Kingdom was at MIT to give a seminar on time sharing. 
Licklider, Davies, and 1 discussed networking and the inadequacy of 
data communication facilities for both time-sharing and networking. 
Davies reports that shortly after this meeting he was struck with the 
concept that a store and forward system for very short messages (now 
called packet switching) was the ideal communication system for inter¬ 
active systems. He wrote about his ideas in a document entitled "Pro¬ 
posal for Development of a National Communication Service for 
On-Line Data Processing" that envisioned a communications network 
using trunk lines from lOOK bits/sec in speed to 1.5 megabits/sec (Tl), 
message sizes of 128 bytes and a switch that could handle up to 10,000 
messages/sec (historical note: this took 20 years to accomplish). Then 
in June 1966, Davies wrote a second internal paper, "Proposal for a 
Digital Communication Network" in which he coined the word packet, 
a small subpart of the message the user wants to send, and also intro¬ 
duced the concept of an "interface computer" to sit between the user 
equipment and the packet network. His design also included the con¬ 
cept of a packet assembler and disassembler (PAD) to interface charac¬ 
ter terminals, today a common element of most packet networks. 

As a result of distributing his 1965 paper, Donald Davies was given 
a copy of an internal Rand report, "On Distributed Communications" 
by Paul Baran of the Rand Corporation, which had been written in 
August 1964 (1). Baran's historical paper also described a short mes¬ 
sage switching network using Tl trunks and a 128 byte message size, 
but was oriented toward providing extremely reliable communications 
for secure voice and data in a military environment. In all, there were 
11 reports written for the Air Force in the Rand Memorandum group, 
of which a couple were classified and unfortunately the others were 
very sparsely published in the scientific press. Thus their impact on 
the actual development of packet switching was mainly supportive, 
not sparking its development—that happened independently at Rand, 
NPL and ARPA. 
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THE FIRST NETWORK EXPERIMENT 


Convinced that computer networking was important, the first task was 
to set up a test environment to determine where the problems were. 
Thus, in 1966, I set up two computer networks between Lincoln Labor¬ 
atory's TX-2 computer and System Development Corporation's Q-32 
computer using a 1200 bps dial channel (high speed in those days). 
Each computer was operating in time-sharing mode and permitted any 
program to dial the other computer, log-in, and run programs much 
as it would execute a subroutine call. The experiment showed that 
there was no problem getting the computers to talk to each other and 
use resources on the other computer; time-sharing operating systems 
made that easy. The real problem uncovered was that dial communi¬ 
cations based on the telephone network were too slow and unreliable 
to be operationally useful. This work, jointly authored with Tom Mar- 
ill, was published in the AFIPS F/CC Proceedings, November 1966 (2). 
The lesson learned was that a new data communications network was 
needed in order to successfully network computers. 

ARPANET DEVELOPMENT 

The chance to develop and build a major computer network experi¬ 
ment based on radically new communications technology came within 
a few months. I was asked to take over the responsibility of the ARPA 
Information Processing Techniques (IPT) office and manage and build 
its programs.* 

ARPA was sponsoring computer research at leading universities 
and research labs in the United States. These projects and their com¬ 
puters provided an ideal environment for an experimental network 
project; consequently, the ARPANET was planned during 1967 with 


'[Edilor's Nnic: In his presentation at the conference, Roberts tolcJ this aneceJote. "We 
realized at that point that the problem was not so much in the computers—the time¬ 
sharing monitors that had been written permitted us to allow computers to be shared 
just fine—the problem was in the communications service. The Western Union circuit 
was . . . terribly unreliable. It took forever to make a call and didn't have any through¬ 
put when you got going. And the cost was enormous. So that was the next job—to 
undertake how to organize the communications resources. All of these experiments 
went on during the mid-1960s. At that point, Ivan Sutherland was finishing his tour 
at ARPA, and Bob Taylor and he were hoping to start some of this network technology. 
They wanted me to come down to ARPA to help with that program. They didn't 
convince me of that, so Bob did what he now says 1 can call 'blackmailing.' He went 
to the director of ARPA and said, 'look, you fund 51 percent of Lincoln Lab. W'hy 
don't you call them up and tell them to send Larry down here?' W'hich Charlie Hirsh- 
feld did, while Bob was there in the room. And the director of Lincoln called me in 
that afternoon and said, '1 think that you really ought to go to ARPA.' 1 wound up 
down there the next week or two, and found mvself working with Bob to set up this 
network program, and eventually taking over the whole program. So, in some sense, 
that was how that activity started. It was not quite what I wanted to do at that point 
in mv career, but 1 found it to be, of course, extremely valuable."] 
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the aid of these researchers to link these projects' computers together. 
One task was to develop a computer interface protocol acceptable to 
all 16 research groups. A second task was to design a new communi¬ 
cations network technology to support 35 computers at 16 sites with 
500,000 packets/day traffic. The initial plan for the ARPANET was 
published in October 1967 at the ACM Symposium on Operating Sys¬ 
tem Principles in Gatlinburg Tennessee (3). The reasons given at that 
time for establishing a computer network were; 

1. Load sharing: Send program and data to remote computer to bal¬ 
ance load. 

2. Message service: Electronic mail service (mailbox service). 

3. Data sharing: Remote access to data bases. 

4. Program sharing: Send data, program remote (e.g., supercom¬ 
puter). 

5. Remote service: Log-in to remote computer, use its programs and 
data. 

The communications network design was that of the now conven¬ 
tional packet network; interface message processors (IMPs) at each 
node interconnected by leased telecommunication lines providing a 
store and forward service on very short messages (Fig. 1). The main 
difference from later packet nets was that the IMPs were located at the 
computer sites and connected by a short parallel cable rather than a 


nCURE 1 

Early communications 
network design with 
IMPs at each node. 
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The ARPANET and Computer Networks 

communications line interface. The device that we used, the IMP, was 
the bieeest minicomputer available at that time, 12K of memory, t was 
a very precious resource. We had to work real hard to get all our stuff 
done and enough buffers within 12K. That probably had more impact 
on some of the technological issues of how you did packet switching 
than anything else that went on because the overall organization was 
focused on eliminating the necessity for buffers. Buffers were obvi¬ 
ously the premium with this size memory. , j 

Also presented at the Gatlinburg Symposium was Donald Da¬ 
vies's first open publication on the NPL packet network concepts pre¬ 
sented by Roger Scantlebury, "A Digital Communication Network for 
Computers Giving Rapid Response at Remote Terminals (4). It de¬ 
tailed the concept of a high-level packet net with high-capacity nodal 
switches and interface computers in front of mainframe computers 
This was the first time that either Davies or 1 knew anything about 
each other's work since our 1965 contact. The NPL paper clearly im¬ 
pacted the ARPANET in several ways. The name "packet was 
adopted, much higher speed was selected (50 Kilobit/sec vs^:L 4 Kilo- 
bit/sec) for internode lines to reduce delay and generally the NPL anal¬ 
ysis helped confirm the concept of packet switching. u 

Another confirmation of the basic concepts came from finally be¬ 
ing able to read the Rand reports on distributed communications. Paul 
Baran had done a vast amount of research in 1962 on packet switching. 
He had designed for the Air Force essentially a telephone system using 
packet switching back in 1962. Some of the reports were classified as 
not in the public domain. Therefore, neither Donald Davies nor I had 
seen anything of the work until we were deep into the design of our 
respective systems. The Rand work was very detailed, since it covered 
the whole network including microwave and one valuable analysis on 
routing. Their hot-potato routing algorithm was a useful starting point 

for the ARPANET routing design. 

In any case, the original published concepts in the Rand reports 
were done by Paul, although we weren't able to utUize those until later 
on in this program. The packets we structured at that point were ones 
that had a header and a content and a check at the end so that they 
said where they were going and had error checking (Fig. 2). We even 
designed a network at this point. It was a hypothetical net, which got 
buUt exactly as planned. I worked out the network technology struc¬ 
ture and the cost effectiveness and the number of hops between all the 
nodes. Eventually, Network Analysis Corporation wound up doing a 
huge amount of the computation of this kind of thing to optimize the 
net for us. It was in 1967 before any net was ever built. Figure 3 shows 
what we thought it might look like and be organized in terms of a 

^ ^ During ^968, a request for proposal was let for the ARPANET 
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FIGURE 2 

Early network packet 
format. 


FIGURE 3 
Physical map 
projecting 
organization of 
ARPANET. 
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The ARPANET and Computer Networks 

packet switching IMP equipment and the oPf^tion of packet net¬ 
work The RFP was awarded to Bolt, Beranek, and Newman Inc., o 
Ombridge MassachuseHs, in Janua^- 1%9. The RFP •>« 

general packet-switching concept, packet size, and T™ j, 

SO that bidders could not totally change the system concept, to circuit 
or meLage switching for example. The two largest computer co^p. 
nies to receive the RFP did not bid it because " , 

computers with which to make an economic bid. BBN bid^^the 
Honeywell 516 minicomputer, which was ideal for the , ■ 

Significant aspects of the network's internal operation, such as rou 
ini flow conmol, software design, and network control were devel 
oped by a BBN team consisting of Frank Heart, Robert^Kahn ev 
O^nstefn William Crowther, and David Walden. By December 1969 

four nodes of the net had been installed and were wire 

The first set of detailed papers covering the ARPANET we 

published in May 1970 at the AFIPS S]CC (5-9)^ These 
The motivation and economics (5), the detailed design o the IMP (6) 
the network delay analysis and experience (7), ® . 

programs and results (8), and the host-to-host protocol (9). These pa 
pers showed the world for the first time that packet switch^ iwrks 
it is ecouomic, and that it is reliable and vntually error free. They also 
provided a complete description of how a working network was de 
signed. As suchj^these papers were the technical and motivational ba¬ 
sis for many other network experiments around the world. 

The ARPANET utilized minicomputers at every node to be se 
by the network, interconnected in a fully distributed fashion by 50 KB 
leased lines. Each minicomputer took blocks of data com¬ 

puters and terminals connected to it, subdivided them into ^28 byte 
packets and added a header specifying destination and source 
dresses; then, based on a dynamically updated routing 
computer sent the packet over whichever free line was c^J^^mly 'h 
fastest route toward the destination. Upon receiving a packet, the next 
^pute, would acknowledge I. and "ng^-ess 

independently. Thus one important characteristic of the ARPANbl 
was fts completely distributed, dynamic routing algorithm on a packet- 
bv packet bLs, based on a continuous evaluation w.lh.n the network 
of the least delay paths, considering both bne availability and queu 

‘'"®The technical and operational success oi the ARPANET quickly 
demonstrated to a generally skeptical world that packet switching 
codd be organized to provide an efficient and ^>8% responsive m er 
active data communications facility. Fears that packets would loop for 
errand that very large buffer pools would be required were quickly 
allaved Since th^ ARPANET was a public project connecting many 
Jiajor unlersities and research institutions, the implementation and 
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performance details were widely published (10-14). The work of Leon¬ 
ard Kleinrock and his associates at UCLA on the theory and measure¬ 
ment of the ARPANET has been of particular importance in providing 
a firm theoretical and practical understanding about the performance 
of packet networks. 

The ARPANET was first demonstrated publicly at the first Interna¬ 
tional Conference on Computer Communications (ICCC) in Washing¬ 
ton, D.C., in October 1972. Robert Kahn of BBN organized the 
demonstration installing a complete ARPANET node at the conference 
hotel, with about 40 active terminals permitting access to dozens of 
computers all over the United States. This public demonstration was, 
for many (if not most) of the ICCC attendees, proof that packet switch¬ 
ing really worked. At this time, it was difficult for many experienced 
professionals to accept the fact that a collection of computers, wide¬ 
band circuits, and minicomputer switching nodes (equipment totaling 
well over 100 pieces) could all function together reliably. The ARPA¬ 
NET demonstration lasted for three days and clearly displayed its reli¬ 
able operation in public. The network provided highly reliable service 
to thousands of attendees during the entire duration of the conference. 


INDUSTRY RECEPTION 

From the first time I distributed a description of packet switching out¬ 
side the computer research community (the 1967 paper) until about 
1975, the communication industry's reaction was generally negative 
since this was such a radically different approach. In some of the initial 
technical speeches I gave, communications professionals reacted with 
considerable anger and hostility, usually saying I did not know what I 
was talking about since I did not know all their jargon vocabulary. The 
most common technical flaw suggested (before the ARPANET was 
built) was that the buffers would quickly and catastrophically run out. 
After the ARPANET was operating successfully, their pitch changed to 
be that packet switching would never be economic without the govern¬ 
ment subsidy. Paul Baran reported the same reaction to his papers 
when he presented them; this reaction was the major reason his pro¬ 
posals never moved the military. Donald Davies reported a somewhat 
less angry response from the British Post Office, more one of mild in¬ 
terest but no serious consideration. 

I learned a major lesson from that experience; People hate to 
change the basic postulates upon which considerable knowledge has 
been built. In the case of packet switching, the first postulate to change 
was the statistical nature of the traffic—data versus voice. The second 
was that computing was expensive. Some people find it is impossible 
to consider such a major jolt to their memory organization; they avoid 
it with putdowns if possible, if not with anger. Other people are more 
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willing to reconsider, but for everyone it requires considerable effort. 
Those of us proposing packet switching all came from the computing 
field and did not need to change lots of prior concepts and knowledge. 
Many of those in the communications field still have not accepted 
packet switching. (The fight is heating up again as voice packet switch¬ 
ing starts to be considered.) 

ARPANET Growth 

As soon as the first four nodes were brought up and tested in Decem¬ 
ber 1969 the network grew very rapidly. One year later, in December 
1970, the network had grown to 10 nodes and 19 host computers. By 
April 1971, there were 15 nodes with 23 host computers, as shown in 
Fig. 4. By this time, it was clear that connecting terminals directly to 
the network through a PAD-type device was important. Such a device 
was designed and built in 1970-1971, and the first terminal interface 
processor (TIP) was added to the network in August, 1971. The TIP 
permitted users to get on the network directly with their terminals so 
that they could have direct access to all of the machines rather than 
having to go through one machine to get anywhere. In many cases, 
having the user attach his terminal to a TIP and access even his own 
host(s) through the network was found to be more reliable. This was 
the start of a trend that today is almost the rule, workstations should 
attach to a network, not a computer. 

By January 1973, the network had grown to 35 nodes of which 15 
were TIPs and was connected to 38 host computers. Figure 5 shows a 


nCURE 4 
The ARPANET in 
April 1971. 
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map of the network at this point. Network traffic had grown rapidly 
in 1972, from 100,000 packets/day to 1,000,000 packets/day, exceeding 
the original estimates I made in 1967. Also in 1973, the first satellite 
link was added to the network with a TIP in Hawaii; later in the year 
a pair of TIPs were added in Europe. In September 1973, the network 
was up to 40 nodes, 45 host computers with internode traffic of 
2,900,000 packets/day, had clearly reached a stage of operational stabil¬ 
ity, heavy usage, and was by any measure a major success. It was at 
this point that I left AREA to spread the technology to the commercial 
world. 

The ARPANET has continued to grow since 1973, with 111 host 
computers in 1977 and more than 400 hosts in all the interconnected 
networks by 1983. The network has become a utility for both ARPA 
and the Department of Defense as a whole. Research has continued 
into internetting and packet radio but little change has occurred in the 
basic network. 
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1969 CROSSOVER 

In 1974, after it was clear that the technology worked, 1 finally spent 
time analyzing the economic trends that made packet switching possi- 
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ble (15). These trends could have been analyzed in the mid-1960s if 
someone were to have asked the right questions, but, as it often turns 
out, they were examined after the event they could have predicted. 
Simply, since packet switching requires more computation than circuit 
switching but saves transmission bandwidth, the trend analysis looked 
at the cost of computation and the cost of communications and found 
the situation illustrated in Fig. 6. For packet switching the cost of com¬ 
putation dominated in the early 1960s but in 1969 the cost curves 
crossed and afterward the cost of communications dominated. The 
composite cost of packet switching thus fell below the cost of circuit 
switching also about 1969 and since then the margin of advantage has 
quickly widened to where it equals the full peak to average transmis¬ 
sion ratio for data of about 8 to 1. Subsequently, in a 1982 paper (16) I 
did a similar analysis for voice and concluded the crossover there was 
in 1978 and therefore packet voice would have been cheaper. In a 
somewhat similar fashion to data, the industry may recognize this ten 
to fifteen years after the event. 




FIGURE 6 

Packet-switching cost 
performance trends, 
incremental cost of 
moving IM bits (1 
kilopacket) on a 
nationwide network. 
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FIGURE 7 
Concept chart of 
effective bandwidth 
versus block size. 


Figure 7 is one of the concept charts that I published of the effec¬ 
tive bandwidth of the system versus block size—much higher effective 
bandwidth than any other technology that we could find for low block 
size. In other words, to get a kilobit somewhere, you could move it 
faster than anything else but, of course, by the time you are moving 
ten million bits, you could move it probably just as well with a number 
of different technologies, including dial technology. But if you were 
going to move short blocks a day, this is by far the fastest. And we 
also looked at costs. Figure 8 shows the cost of different technologies, 
from telegram at the top at $3300 per million bits, down to mailing a 
tape at 3 cents per million bits. Of course, today, we have the new 
option of sending a CD-ROM by courier anywhere in the world and 
having the lowest possible cost that you can imagine for high speed 
delivery. In fact, the effective bandwidth is over a hundred kilobits per 
second. 

The costs versus delay was a big issue, as shown in Fig. 9. The 
cost per megabit was in the 16-cent range in a well-loaded network. 
The other axis is delay. The higher the delay (where the delay is for 
dial-up), the worse off your users are in terms of doing the job. But 
still the cost couldn't get down anywhere near as low. 

The actual traffic on the net grew very rapidly in 1973 to where 
we had a reasonable loading in terms of network activity. The cost 
versus network size is shown as one upper line of Fig. 10; the lower 
section, in color, was projected for commercial networks. Actually, 
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figure 8 

Costs of different 

communications 

technologies. 
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FIGURE 9 
Costs versus delay. 
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FIGURE 10 
Cost relative to 
network size. 
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numbers on this chart typically would indicate that the commercial net¬ 
works charged more than they needed to, and they did because they 
had to do so much more work training the users than we allocated in 
this chart. This is pure cost of communications rather than the cost of 
running a service. The top of the chart basically says that the vertical 
column is the cost per million bits, again of moving data; the middle 
band is between a dollar and ten cents for the cost of communications 
over the years from 1960 to 1980. 

The cost to deliver goes down by a factor of ten every five years. 
This is a consistent trend that includes the cost of packet switches. The 
communications trend indicated a sort of flattening out by 1980. What 
actually happened to communications is that it turned around and 
started going up again. If you examine communications costs later on. 
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you find that tariff situations and other situations (i.e., primarily the 
FCC and AT&T fighting) caused that trend to back up again over time. 
They didn't stay on the downward side, even though the technology 
trend for installed plant has continued to go down. 


IMPACT ON COMPUTER RESOURCES 

One of the original goals of the ARPANET was resource sharing to 
optimize computer resources. In 1973 I surveyed the ARPANET users 
to see what alternative computer facilities they would need if they did 
not have the network (Tables 1 and 2). In a number of cases there were 
ARPA projects that did not have a computer at all but utilized com¬ 
puter power from resource centers that had developed. They obtained 
access through a TIP, typically on site, and used one of a collection of 
computers often across the country. They were generally happy not to 
have to run their own computer and had far more reliable service than 
if they had been limited to one machine. Also, due to the statistics of 
large groups and the benefit of multiple time zones (from Hawaii to 
Europe), the number of computers required for these users was far less 
through consolidation. Another group of users were using the Illiac IV 
remotely for large numerical problems and would have required their 
own supercomputer or perhaps had to commute if the network were 
not there. In other cases individuals needed to use software unique to 
foreign hardware and thus needed access to other computers besides 
their own. After finding rational solutions (fiscally sound) to all the 
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ARPA user needs assuming no network, the computing cost was com¬ 
pared to the then actual computer cost and found to be three times as 
expensive. Independent of the details of the survey, it is clear that huge 
savings were possible (in that era of mainframes) by pooling comput¬ 
ing demand. Today, when all my computer resources come from mi¬ 
crocomputers, I couldn't save anything using remote computers for 
computing power. Supercomputer users still might save but, in large 
part, this benefit is mainly historical. 


Other Network Development 

CYCLADES 

In France the interest in computer networks grew quickly during the 
early 1970s. In 1973 the first hosts were connected to a network called 
CYCLADES that linked several major computing centers throughout 
France (17). The name CYCLADES refers to both the communications 
subnet and the host computers. The communications subnet by itself 
is called CIGALE and is a pure datagram network, moving only discon¬ 
nected packets and delivering them in whatever order they arrive with¬ 
out any knowledge or concept of messages, connections, or flow 
control. The ARPANET also operates using datagrams but perhaps the 
most avid supporter of the concept is the designer of CYCLADES, 
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Louis Pouzin. As with any datagram network, a large part of the com¬ 
munications functions must be implemented in the host computers; 
the packet ordering, message formation, flow control, and virtual con¬ 
nections support. 


Another packet network experiment was started in France at about the 
same time by the French PTT Administration (18). This network, RCP, 
first became operational in 1974 and was the experimental testbed for 
the French public network service TRANSPAC. The design of RCP, di¬ 
rected by Remi Despes, differed sharply from that of CIGALE and 
ARPANET by being organized around the concept of the virtual circuits 
rather than datagrams. RCP's character as a prototype public network 
may have been a strong factor in this difference since a virtual circuit 
service is more directly marketable, not requiring substantial modifica¬ 
tions to the customers' computer. In any case, RCP pioneered the in¬ 
corporation of individually flow-controlled virtual circuits into packet 
switching networks. 


TELENET 

The success of the ARPANET led Bolt, Beranek, and Newman (the pri¬ 
mary contractor for the ARPANET) to establish a commercial network 
company. Telenet, in late 1972. In October 19731 joined Telenet as pres¬ 
ident, and we fOed with the FCC to become a carrier and construct a 
public packet switching network. The FCC approved the request six 
months later, and Telenet started the world's first public service in Au¬ 
gust 1975 with 7 nodes. By April 1978 Telenet's network had grown to 
187 nodes providing service to 180 host computers and supporting di¬ 
rect terminal access service in 156 cities and interconnections to 14 
other countries. Telenet was designed from the start to appear to the 
user as a virtual circuit service with the host interface being imple¬ 
mented over a communications line rather than with a box on site. 
However, for the first several years Telenet operated a core network 
based on datagrams copied from the ARPANET, but implemented vir¬ 
tual circuits at all interfaces. It used a device that is similar to the IMP 
in structure but, as a central office device so that the user was over a 
communication line, rather than having a device at his site (Fig. 11). 
And the work piled into the site for terminal access. So we had what 
we called TIPs in all of our central offices and they connected by remote 
lines to the user site. And then we might have a small device called 
the TAC to break it out to individual lines for that computer, or an X.25 
or similar protocol line to the user. When Telenet started, there wasn't 
any X.25; we had a similar protocol. Within a year, we had changed to 
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FIGURE 11 

Telenet central office 

device. 
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the now’ standard X.25. The machines we were using at that time were 
Prime computers, somewhat better cost effectiveness than the original 
Honeywell machines, but similar in concept. 

It wasn't until the complete shift was made to Telenet's TP-4000 
packet switch around 1980 that the savings of virtual circuits in the 
core net could be realized (about 30 percent for Telenet with a 32 byte 
average packet size). The communications capability that we were able 
to offer computing power for at that point was something on the order 
of S2 an hour for interactive access nationwide, from any place to any 
place. You dialed into the network and got to another city for $2 an 
hour, as opposed to what the dial telephone network charges were at 
that point, something like $25 an hour. So it was cheaper, by about a 
factor of ten, than what you could do over the telephone network. In 
the intervening time, packet network charges have gone up to some¬ 
thing like $4 to $5 an hour, and the telephone charges have come down 
somewhat from the $25 range to more like $15 or $20. So you see a 
flattening of the two with respect to each other. 

We also looked at where packet switching was most effective as 
shown in Fig. 12. It was obviously most effective for interactive termi¬ 
nals where the average utilization of the terminal on the vertical axis 
was very low (between 5 and 10 percent). The peak transmission rate 
was relatively low for terminals between 4.8 kilobits, on down; in that 
range, we could provide very cheap service and have a very cost effec- 
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FIGURE 12 
Packet-switching cost 
versus utilization 
levels. 



tive situation. When you get the very high percentage utilizations, 100 
percent utilization and very high speeds, of course, you virtually need 
a dedicated line between the two sites. The diagonal lines are what it 
would cost to provide packet switching at the then tariff prices for 
packet switching for all these services. You see that batch was quite 
attractive as compared to dial telephone, which was again still $25, 
and even voice; most of voice, if compressed at all, was attractive and 
still is. 

The next issue that came up was that the right way to do things 
was to use datagrams. We had lots of communications capacity, basi¬ 
cally because we were using 56 kilobit lines and very few buffers—very 
little to work with in the computer room. That quickly changed as the 
cost of computing continued to go down even after 1973, and it has 
gone down by another few orders of magnitude since then. So now 
the cost is practically nothing. By the time Telenet was built, there were 
plenty of buffers available. There is no issue about reassembling and 
doing all sorts of work to set up to understand the packets at each end 
of a link. Therefore, the best thing to do is to pre-figure what's going 
on and store it at both ends, both of the computers and both ends of 
each link in the network. Just send a very short piece of header on the 
packets saying this is call #27 and send the data and a sum check. What 
we originally did in the ARPANET was to send to and from big long 
addresses that identified everybody and where it was going to and 
from. That took 31 bytes of overhead, whereas we could get that down 
to 10 bytes in the upper one. In fact, when you look at a voice packet 
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FIGURE 13 
Single-level versus 
two-level topology. 


switch that you'll be seeing in the late 1980s and the 1990s, we're down 
to maybe 8 bits, 1 byte of overhead on that packet, and everything 
else is data because you have to have very short packets. So we're 
progressing to much shorter headers because of the overall capability 
of the computer site. We can have lots of computer capability to do the 
best job we can. And there's no sense wasting that huge amount of 
overhead. When the average data in fact was only 30 bytes, or 20 bytes, 
in the average call packet, then we were wasting 50 percent of our 
bandwidth and processing power handling all of that data. And so, as 
it turns out, that was a major change that took place in the packet 
networks that we've done commercially from the research networks. 
There were all sorts of claims that it was less reliable or other things; 
yet all those problems had been solved. Today the issue remains a de¬ 
bate between the various parties. 

Telenet also went to a two-level hierarchy where you have central 
net, very heavy circuit, and a lot of finer circuits moving into those. 
And one of the other things that was looked at was, what is the effect 
of a two-level topology (Fig. 13). The top net shows a single-level net¬ 
work like the ARPANET where every node is equal, every node has 
four lines connecting to it forming an almost random pattern. The aver¬ 
age path length is proportional to the log of the number of nodes, log 
base three, because you have three additional lines connecting to each 
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node. In a two-level network, which you see at the bottom of the fig¬ 
ure, you have a central network and then a bunch of other nodes on 
the outer nets, four lines for a node on the average. But every node 
doesn't have four lines—some have many more, some have less, the 
average path link was three minus a small amount. The delay and the 
cost in the network, because every line you traverse costs you money, 
is proportional to the average path line. So, if you then look at cost of 
the network, the path link in the network, which is proportional to 
cost efficiency of the use of the network, you find that the path link 
and hops for a single-level network keeps going up as the log for the 
number of nodes. Above a hundred nodes, it s far cheaper to have a 
two-level network. That was what happened in the commercial envi¬ 
ronment as well. 

The processor we used at that point was called TP. Telenet still 
uses them, ten years later. We designed a multi-processor device that 
processed the packets and had a much higher throughput than the 
original processors. 

The international network quickly built up then where Telenet, in 
particular, was interconnected with a vast number of countries as well 
as TYMNET in the United States, and any other network that came 
along in time. There were a number of commercial networks in the 
United States and a number of overseas networks like those in the 
United Kingdom and Canada. Soon after this, France and other na¬ 
tions had their own major networks; but many of them just had nodes. 


Originally known as COST Project II and later as the European Infor¬ 
matics Network, EIN is a multi-nation funded European computer net¬ 
work (19,20). The project director was Derek Barber of NPL, one of the 
original investigators of packet switching in the United Kingdom. It 
was organized in 1971 but due to the difficulties of multi-national fund¬ 
ing it did not become operational until 1976. 


OTHER PUBLIC DATA NETWORKS 

Public packet networks were announced in the United Kingdom, 
France, Canada, and Japan in the 1973-1974 period. In 1977 the Experi¬ 
mental Packet Switched Service (EPSS) in the United Kingdom and 
DATAPAC in Canada became operational. Also in 1977 a second public 
network TYMNET became approved in the United States. In 1978 
TRANSPAC in France and DX-2 in Japan became operational as public 
networks. By the early 1980s public packet network service was avail- 
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able in most countries in the world as an international service and as 
a domestic service in many of these countries. 

CCITT Standards—X.25 

With five, independent, public packet networks under construction in 
the 1974-1975 period (U.S.—Telenet, Canada, U.K., France, Japan), 
there was strong incentive for the nations to agree on a standard user 
interface to the networks so that host computers would not have 
unique interfacing jobs in each country. Unlike most standards activi¬ 
ties, where there is almost no incentive to compromise and agree, carri¬ 
ers in separate countries can only benefit from the adoption of a 
standard since it facilitates network interconnection and permits easier 
user attachment. To this end, the parties concerned undertook a major 
effort to agree on the host-network interface during 1975. The result 
was an agreed protocol, CCITT Recommendation X.25, adopted in 
March 1976. 

The X.25 protocol provides for the interleaving of data blocks for 
up to 4095 virtual circuits on a single full-duplex leased line interface 
to the network, including all procedures for call setup and disconnec¬ 
tion. A significant feature of this interface, from the carriers' point of 
view, is the inclusion of independent flow control on each virtual cir¬ 
cuit (VC); the flow control enables the network (and the user) to pro¬ 
tect itself from congestion and overflow under all circumstances 
without having to slow down or stop more than one call at a time. In 
networks like the ARPANET and CYCLADES, which do not have this 
capability, the network must depend on the host (or other networks in 
interconnect cases) to ensure that no user submits more data to the 
network than the network can handle or deliver. The only defense the 
network has without individual VC flow control is to shut off the entire 
host (or internet) interface. This, of course, can be disastrous to the 
other users communicating with the offending host or network. 

Another critical aspect of X.25 is that it defines interface standards 
for both the host-to-network block transfer and the control of individ¬ 
ual VCs. In datagram networks the VC interface is situated in the host 
computer; there can be, therefore, no network standard for labeling, 
sequencing, and flow controlling VCs. 

The March 1976 agreement on X.25 as the technique for public 
packet networks marked the beginning of the second phase of packet 
switching: large interconnected public service networks. In the years 
since X.25 was adopted, many additional packet standards have been 
agreed on as well. X.28 was adopted as the standard asynchronous 
terminal interface and X.29, a protocol used with X.25 to specify the 
packetizing rules for the terminal handler, was adopted as the host 
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control protocol. Also, a standard protocol for interconnecting interna¬ 
tional networks, X.75, has been adopted. 


Packet Switched Voice 

Packet networks today typically only utilize trunks and lines up to 64 
kilobits/sec in speed. As a result, end-to-end delay in these networks 
remains high—over 100 ms. Network delay would however be vastly 
reduced given high speed trunks (T1-T3) and high speed packet 
switches (greater than 100,000 packets/sec). Even with a shift to T1 
trunks, the network delay would drop to 10 ms plus propagation. With 
T2 trunks, the delay would not be practically different than with a cir¬ 
cuit switch (1-2 ms plus propagation). For most data applications this 
is unnecessary but for voice it is critical. The voice network will often 
return an echo from analog phones and even 20 ms of delay can make 
such an echo sound bad. Short packets like 32 bytes (4.5 ms of 56 kb 
voice) are also necessary to reduce delay. But with high speed trunks 
and short packets, packetized voice is not only toll quality but also 
saves 67 percent of the transmission and switch bandwidth due to si¬ 
lence suppression. Thus in designing tomorrow's central office switch 
and toll switches for the telecommunications network, it is clearly ex¬ 
tremely desirable to use packet switches for voice of any rate (56kb, 
32kb, 16kb, etc.), for data of all speeds and for switched video. Without 
packet switching the flexibility is vastly reduced and each service must 
be switched separately. Packet switches of the required speed are both 
feasible and economic today if restricted to fixed-length, short packets 
(16 or 32 bytes), all flow control and error checking are done at the 
network interfaces—not for each link, and a foreshortened virtual cir¬ 
cuit header is used (about 1 byte) with only the link number. AT&T 
has a prototype switch of 2 million packets/sec in test and designs exist 
for switches up to 35 million packets/sec (21). 

The most interesting facet of high speed switch technology is that, 
for large central office or tandem office switches, the peak switch 
throughput is limited by the speed of the fastest memory for a time 
switch and similarly for a packet switch, but the packet switch is able 
to switch a whole packet not just one byte like the time switch. Thus 
in general for 32 byte packets, packet switches can be made about 32 times 
the maximum throughput of circuit switches. This becomes very valuable 
at high level tandem switching offices to switch traffic between many 
fiber paths. 

Based on the importance of coping with variable bitrate demands 
for data, voice, and video and the cost savings for integrating all ser¬ 
vices with one switch, it is clear that the whole telecommunications plant 
will convert to packet switching in the future. The date is harder to predict 
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but conversion should occur during the 1990s and be complete by 2000. 
The basic service will be small packets on virtual circuits, and each 
application will have its own interface units. Data services will use an 
X.25 interface that does the flow control and error checking for the VC 
on an end-to-end basis. 

Future Computer Networks 

If we look forward to the year 2000, based on historical trends, com¬ 
puters will be about 500 times cheaper per computation than today. 
Almost all devices in the home, office, or plant will have complex com¬ 
puters incorporated into them. Simple local area network facilities like 
shielded twisted pair will connect the majority of these together and a 
gateway will connect this local network to the public telecommunica¬ 
tion system over (hopefully a revised and truly integrated) ISDN facil¬ 
ity. Distinctions as to which device is the phone may become difficult 
because many of the device-computers may use the voice network 
from time to time for warnings, ordering, and certainly in assisting us 
to find the party to whom we wish to talk. Phone service today is in 
great need of automation; we waste large amounts of time nonproduc- 
tively answering and calling to find people. Thus as the telecommuni¬ 
cations network brings data and voice together, home and office 
automation will integrate them. 
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As an ARPANET user in the early 1970s, I remember seeing some sta¬ 
tistical reports concerning the traffic patterns on the network. Specifi¬ 
cally, the usage for electronic mail purposes was significantly high, or 
maybe surprisingly high. 1 wondered whether you, at that time, were 
alarmed by that kind of pattern, or whether some people suggested to 
you that that was not substantive enough use of such a sophisticated 
technology. Or did you foresee such use as a significant need to be 
met in the future of person-to-person communication? 

Well, we were surprised that it happened, although not totally because 
we had spent a lot of our time developing electronic mail. We thought 
it was fantastic as a capability. The ARPA office was one of the largest 
users; the ARPA office converted totally. Steve Lucasick decided it was 
a great thing, and he made everybody in ARPA use it. So all these 
managers of ballistic missile technology, who didn't know what a com¬ 
puter was, had to start using electronic mail. 1 think it went over very 
well inside and externally; it was probably a larger factor than we had 
imagined it would be. I remember getting a note back from Paul Baran 
when we were starting on this (1 looked it up the other day when I 
was running through all this stuff). It said, "These are all fine, what 
you're talking about for this network. But one thing you ought to 
watch out for is you can't send out personal message stuff, that's ille¬ 
gal. That's against the postal laws and you'll be in jail in no time." 
And it happened, but we didn't happen to go to jail. 

If we're looking for the important factors that make these things 
happen, then, relative to the discussion of ARPA, it is worth re¬ 
emphasizing something Larry said: ARPA could remain very cool and 
easy with respect to the fact that the research community, who it was 
advertizing as its initial customer, was fairly cool about the net. ARPA 
had the freedom to pursue a development path for quite a long time, 
without necessarily getting everyone behind it as certified customers 
before they were able to proceed. That turned out, in retrospect, to be 
exactly the right strategy to make things work. 

To come back to an earlier issue, there is a fairly strong flavor in 
the meeting so far of "technological determinism." If you simply lay 
out the physical structure of what happened, then everything else falls 
into line. Gordon's talk, and Larry's talk to a certain extent (because 
that's what was on his slides), did not focus simply on the characteris- 
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tics of discovery, not on the characteristics of who did what when, but 
just on laying out the major economic and technological factors that 
seemed to hedge the whole development and make it go in particular 
ways. One wants to keep looking for the factors that work in the oppo¬ 
site fashion. One was the issue that we brought up earlier, on the 
workstation. It was the research community that didn't necessarily 
want to go do the workstation that kept it from happening. Lick said 
it w’as the community's fault, and Butler Lampson said that they were 
not interested in it because the technology was too hard. Yet, in fact, 
we—ARPA and the community—did a fair number of things in areas 
where the technology was not available. The network is an example of 
one area where ARPA forced the technology by several years, and you 
hung in there. Speech was another example where the technology 
wasn't really right there, and you took it as your job to force it. Yet, 
somehow, ARPA never took it upon itself to force the workstation tech¬ 
nology as a concept in the long term. I'm not concerned about rela¬ 
tively isolated things like the KLUDGE. For the network, and for 
several other things that ARPA did, they did it on a scale and for long 
enough that it actually made the world change. I wonder if you have 
any reflections on that? 

Workstation development could do quite well on its own. It was quite 
within the economic capacity of commercial organizations. As you see 
today, commercial organizations are quite interested in such develop¬ 
ment. So that was one of the criteria that we built up: Don't fund any¬ 
thing that was obviously going to be done by industry and was 
straightforward. Rather, fund things that are further out. Butler re¬ 
ferred to another example. After the Illiac IV, we decided that we had 
had enough of this, and we will not undertake another supercomputer 
project. But, I think the thing that stopped the work on the personal 
workstation was that we had all seen plenty of the research that would 
have led to it—the graphics work and everything else that had been 
done. The issue was that it needed to become a commercial reality, and 
making a commercial reality wasn't ARPA's job. But, and now I go 
back to some of the earlier parts of what you said, I think that it's very 
true that the technology is a forcing factor that brings you there. As 
you saw in the network research, we could have gone for I think 
another five years and never had a network if it wasn't for the ARPA 
office being as free as it was to pursue development. The voice network 
has not appeared because there hasn't been that kind of undertaking. 

We're using the word ARPA or DARPA very loosely in this. Sometimes 
it means the collective set of contractors, sometimes it means a little bit 
of guidance from the top, where a lot of thousand flowers bloom. But, 
in fact, in this thing we really shouldn't be using "DARPA"; it was a 
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few people, and namely Larry, who drove it. 1 wouldn't say it could 
have been stopped, perhaps because of the ARPA community getting 
up in arms at not being funded on their own. They took money out of 
the communal tree and funded this thing. I think Larry's being very 
generous. Things could have been much worse; it could have been a 
decade before this happened. I was in this a little bit, too. 1 had enough 
dealings with the communications suppliers that it is hard for me to 
believe that it could ever have happened, left to its own devices. It 
took an individual and it took the experiment to get it to happen. This 
is one of the cases where the thing wouldn't have happened by itself. 
The workstation happened almost because of the known technology, 
but packet switching really wasn't happening. We saw the need for it 
once we built all those minicomputers. We had to have DEC-net and 
so, in the 1973 to 1974 timeframe, we said we've got to hook these 
workstations together, and our model was all of the packet switching 
that was done in the community. We did it a little bit differently, using 
the host, but the ARPANET was clearly the model. It was also the 
model for expanding local area networks (LANs). In fact, there were 
lots of LANs proposals that were pre-packet switching: loops, pierced 
loops, and a lot of work at IBM. But this was truly an individual driving 
it, and it could have been dwarfed, both by the technologists (the com¬ 
munications supplier) and by the other guys who had gotten screwed 
by it, the ARPA users. 

To pick up on Allen's question on why ARPA didn't carry through 
further with the workstation concept, I think that the thinking and 
practice was really focused on the workstation, the WS part (to take 
the point I was trying to make in my paper) and the software architec¬ 
ture. It was less focused on questions about the users' personal work 
habits. This was very hard to get hold of, especially when the big break 
took place in going to the PLl/MULTICS root as the primary time¬ 
sharing support of ARPA, and then the still different 940 stuff that led 
to the other packet switching and so forth. There was a break in the 
underlying software technology that had to be reinvented later in the 
process by the marketplace. 

I thought I'd add a little bit of perspective; I'm a little more recent than 
Larry from ARPA. In fact, I can remember a number of discussions at 
ARPA, while I was there, about the issue of whether we should sup¬ 
port the workstation work going on. And the position really was what 
Larry just described—that it was appropriate for ARPA to support basic 
research in areas where it could be used to help drive workstation de¬ 
velopment, but it was inappropriate to go develop workstations be¬ 
cause, after all, the commercial world could do that very well and, in 
fact, did, with ARPA encouragement, but not support. 
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Thank you, I didn't have the perspective of the last years, but I sus¬ 
pected that that was certainly the case. Certainly when I was there it 
would have cost us $100,000 a workstation, and that's a little bit ex¬ 
pensive. 

One of the major impacts of the ARPA networking on workstations 
today that hasn't been explicitly mentioned is the protocol architecture 
that came out of the ARPA community ten years ago or so. Much of 
the networking of workstations has been accomplished using militar}’ 
standard protocols; there are some obvious products in the market¬ 
place today that use those. 1 think that has to be recognized. Yet one 
of the maybe not-so-successful impacts was selling those protocols to 
the international standards community. Now we're faced with the sit¬ 
uation where DOD is under pressure to abandon those military stan¬ 
dards in favor of international standards. What is the impact of that 
going to be on the marketplace, and on products that have been built 
up based on those military standards? Do you have any observations 
on that? 

My own observation I already gave. I think the military standard is 
obsolete by this point in time so that the commercial standard is what 
most people have built commercial products around, as far as I can 
see. I'm not too concerned with that trend. I think it's just correct. 

I've got to comment on that one. I actually believe the ISO protocols, 
the international protocols, are one of the sterling successes of ARPA. 
ARPA's business is to develop technologies not standards and, while 
the standards that ARPA developed may not be used exactly the way 
they were developed in the military context of the ARPA research, in 
fact, if you take a look at the ISO protocols, a good many of them are 
technologically quite similar, maybe updated for newer technology, 
but still technologically quite similar to the DOD protocols. The ques¬ 
tion is how to transition inside the DOD and how to transition in some 
of the other communities that are using the DOD protocols to leapfrog 
into the ISO protocols because, after all, the ISO protocols are still not 
a usable set of protocols. There's a lot missing in them yet. 




